Graceful Restart (GR) refers to a technique that ensures normally going on of data forwarding and ensures critical services being uninterrupted when a protocol is restarted. The GR technique is one of High Availability (HA) techniques. The HA is a whole set comprehensive technologies, including redundant fault-tolerant, link guarantee, node fault recovery and flow engineering. GR is a redundant fault-tolerant technique, which, at present, is broadly used inactive/standby switchover and system update, in order to ensure an uninterrupted forwarding of critical services.
Currently, multiprotocol label switching (MPLS) protocols that support GR include: Label Distribution Protocol (LDP) and Resource Reservation Protocol (RSVP). The two protocols add parameters in relation to GR in initializing message of the protocol when supporting GR, and such parameters interact when neighbor relationship is established between routers to help GR's proceeding.
Taking LDP as an example, the current GR process is explained, as shown in FIG. 1, and its specific steps are as follows:
Step 101: Router A determines that neighbor router B is restarted and enters GR status, taking itself as helper end while starting a connection timer.
Step 102: The router A searches LSP of the neighbor router B in itself, and marks on the LSP.
The LSP will be interacted when the router A and router B establish a neighbor relationship.
Step 103: The router A sends a neighbor relationship establishing message to the neighbor router B.
Step 104: The router A determines whether a neighbor relationship establishing message sent by the neighbor router B is received prior to timeout of the connection timer; if yes, the process proceeds to step 105; otherwise, the process proceeds to step 106.
Step 105: The router A keeps the GR status, sends the marked LSP to the neighbor router B, and this flow terminates.
Step 106: The router A deletes the marked LSP and quits the GR status.
Currently, an LDP-supported router determines that a neighbor router restarts mainly through the following manners:
Manner 1, the router detects that the Transmission Control Protocol (TCP) interface with the neighbor router is close, and then determines that the neighbor restarts.
Since the LDP runs on TCP, when the TCP connection breaks, the LDP certainly is disconnected.
Manner 2, the router detects that the HoldTime timer for maintaining the neighbor relationship is timeout, and then determines that the neighbor router restarts.
The HoldTime timer is the timer configured to maintain neighbor relationship. If the router fails to receive a Hello message sent by the neighbor router within timing period of the HoldTime timer, then it deems the neighbor router restarts.
The RSVP-supported router will determine the neighbor relationship breaks and then deems the neighbor router restarts when it fails to receive the Hello message sent by the neighbor router three times of continuous.
It can be seen that both of the LDP-supported router and the RSVP-supported router determine that the neighbor router restarts by detecting the turning off of the neighbor relationship. However, in fact, the neighbor router might not restart when the neighbor relationship breaks. For example, it is possible that the neighbor router cannot send out the Hello message in time due to the system being busy or due to the problem of protocol process per se. At this time, the local router might deem the neighbor router restarts when it detects that the neighbor relationship breaks; or, in the case that two routers connect via a switch, when the physical link of one of the routers goes wrong, the other might deem the neighbor router restarts as the turning-off of the neighbor relationship is detected. The above cases may cause the router entering into GR status by mistake.
The following disadvantages may result from the entering into GR status by mistake:
1. It will cause unnecessary signaling between routers, data interaction, and occupancy of CPU resources.
2. It might cause failure of data forward, the reason is that, considering that some routes in relation with a router might shock when the router being in GR status, current protocols prescribes that when a router is in GR status, the route newly generated on this router cannot use LSP that the route assigned before entering into GR status but being invalid when being in the GR status corresponds to. That is, when the router enters GR status, if it detects a route that a certain assigned route that the LSP corresponds to is invalid, then the LSP cannot be released immediately, but be preserved to the end of the GR status; and when the GR status terminates, if the route that the LSP corresponds to is still unavailable, then the LSP will be released to be assigned to a newly generated route for usage. Obviously, this may result in the following problems: if the amount of the routes newly generated by the router is large when the router is in GR status, then it is possible to result in that the LSP of the router not enough, making the newly generated routes being unavailable due to no LSP being able to be assigned, so that data forward will fail. For example, a certain router can support 100 thousand pieces of LSPs at most, before the router enters GR status, it has assigned 90 thousand pieces of LSPs to generated routes, then when the router is in GR status, it can only assign 10 thousand pieces of LSPs more, if the amount of the newly generated routes when being in GR status is more than 10 thousand, e.g. 30 thousand, then there will be 20 thousand pieces of routes unavailable as they cannot be assigned LSP, so that 20 thousand destination addresses cannot reach in the period of GR status.
Thus, when entering GR status by mistake, it must be detected in time and quitted, in order to eliminate persistent duration of the wrong GR status.